Does rector report back the files that it has actually modified? If so I would auto run the linter for the modified files, thereby avoid having to run it for all files within a folder.

This linter is separate from the rector, since rector isnt so much the issue as other regex based changes done, or IDE based replace.

This could be an additional thing for rector runs on top, but IMO a separate topic.

And yes, I think we could in general extract the files changed in rector output

1) ../../app/src/Controller/UsersController.php:8210

With --per-file this would be easier as we directly know the files that we touch.

Does rector report back the files that it has actually modified? If so I would auto run the linter for the modified files, thereby avoid having to run it for all files within a folder.

its not also about rector creating broken files but rector will also break, if you pass it broken files.
So its good to execute this command BEFORE doing the rector to make sure everything can be parsed into an AST by rector.

Having this as a separate command command is totally fine. I just think that having it auto-run for modified files (by rector or regex) would save time, instead of having to run it again for a full directory/app.

I like the additional idea of --lint on the rector command to have a (pre and) post run of it, especially before storing it.

Wouldn't using/wrapping something like https://github.com/php-parallel-lint/PHP-Parallel-Lint make more sense than having our own implementation?

I am fine with a dependency, just thought maybe having an easy tool suffices here.